An interdisciplinary perspective of dependability in Open Source Software

Open Source Software (OSS) development needs to be considered during software development as to whether to develop an OSS packages, and/or whether to develop with OSS. In this paper we briefly summarize the various characteristics that can be used to describe an OSS project and then explore the possible relationships between OSS products/projects and dependability

Software architectures and Open Source Software: Where can research leverage the most?

Software architectures have been playing a central role in software engineering research for some years now. They are considered of pivotal importance in the success of complex software systems development. However, with the emergence of Open Source Software (OSS) development, a new opportunity for studying architectural issues arises. In this paper, we introduce accepted notions of software architectures (Section 2), discuss some of the known issues in OSS (Section 3), resulting in a set of aspects we consider to be relevant for future research (Section 4)

Creating product line architectures

The creation and validation of product line software architectures are inherently more complex than those of software architectures for single systems. This paper compares a process for creating and evaluating a traditional, one-of-a- kind software architecture with one for a reference software architecture. The comparison is done in the context of PuLSE-DSSA, a customizable process that integrates both product line architecture creation and evaluation

Interdisciplinary insights on Open Source

The term “open source” is widely applied to describe some software development methodologies. This paper does not provide a judgment on the open source approach, but exposes the fact that simply stating that a project is open source does not provide a precise description of the approach used to support the project. By taking a multidisciplinary point of view, we propose a collection of characteristics that are common, as well as some that vary among open source projects. The set of open source characteristics we found can be used as a tick-list both for analysing and for setting up open source projects. Our tick-list also provides a starting point for understanding the many meanings of the term open source

PuLSE-I: Deriving instances from a product line infrastructure

Reusing assets during application engineering promises to improve the efficiency of systems development. However, in order to benefit from reusable assets, application engineering processes must incorporate when and how to use the reusable assets during single system development. However, when and how to use a reusable asset depends on what types of reusable assets have been created.Product line engineering approaches produce a reusable infrastructure for a set of products. In this paper, we present the application engineering process associated with the PuLSE product line software engineering method - PuLSE-I. PuLSE-I details how single systems can be built efficiently from the reusable product line infrastructure built during the other PuLSE activities

Implementation issues in product line scoping

Often product line engineering is treated similar to the waterfall model in traditional software engineering, i.e., the different phases (scoping, analysis, architecting, implementation) are treated as if they could be clearly separated and would follow each other in an ordered fashion. However, in practice strong interactions between the individual phases become apparent. In particular, how implementation is done has a strong impact on economic aspects of the project and thus how to adequately plan it. Hence, assessing these relationships adequately in the beginning has a strong impact on performing a product line project right. In this paper we present a framework that helps in exactly this task. It captures on an abstract level the relationships between scoping information and implementation aspects and thus allows to provide rough guidance on implementation aspects of the project. We will also discuss the application of our framework to a specific industrial project

Security-aware selection of Web Services for Reliable Composition

Dependability is an important characteristic that a trustworthy computer system should have. It is a measure of Availability, Reliability, Maintainability, Safety and Security. The focus of our research is on security of web services. Web services enable the composition of independent services with complementary functionalities to produce value-added services, which allows organizations to implement their core business only and outsource other service components over the Internet, either pre-selected or on-the-fly. The selected third party web services may have security vulnerabilities. Vulnerable web services are of limited practical use. We propose to use an intrusion-tolerant composite web service for each functionality that should be fulfilled by a third party web service. The third party services employed in this approach should be selected based on their security vulnerabilities in addition to their performance. The security vulnerabilities of the third party services are assessed using a penetration testing tool. In this paper we present our preliminary research work

Architectural mismatch tolerance

The integrity of complex software systems built from existing components is becoming more dependent on the integrity of the mechanisms used to interconnect these components and, in particular, on the ability of these mechanisms to cope with architectural mismatches that might exist between components. There is a need to detect and handle (i.e. to tolerate) architectural mismatches during runtime because in the majority of practical situations it is impossible to localize and correct all such mismatches during development time. When developing complex software systems, the problem is not only to identify the appropriate components, but also to make sure that these components are interconnected in a way that allows mismatches to be tolerated. The resulting architectural solution should be a system based on the existing components, which are independent in their nature, but are able to interact in well-understood ways. To find such a solution we apply general principles of fault tolerance to dealing with arch itectural mismatche

Algebraic totality, towards completeness

Finiteness spaces constitute a categorical model of Linear Logic (LL) whose objects can be seen as linearly topologised spaces, (a class of topological vector spaces introduced by Lefschetz in 1942) and morphisms as continuous linear maps. First, we recall definitions of finiteness spaces and describe their basic properties deduced from the general theory of linearly topologised spaces. Then we give an interpretation of LL based on linear algebra. Second, thanks to separation properties, we can introduce an algebraic notion of totality candidate in the framework of linearly topologised spaces: a totality candidate is a closed affine subspace which does not contain 0. We show that finiteness spaces with totality candidates constitute a model of classical LL. Finally, we give a barycentric simply typed lambda-calculus, with booleans ${\mathcal{B}}$ and a conditional operator, which can be interpreted in this model. We prove completeness at type ${\mathcal{B}}^n\to{\mathcal{B}}$ for every n by an algebraic method

Block public access: Trust safety verification of access control policies

© 2020 Owner/Author. Data stored in cloud services is highly sensitive and so access to it is controlled via policies written in domain-specific languages (DSLs). The expressiveness of these DSLs provides users flexibility to cover a wide variety of uses cases, however, unintended misconfigurations can lead to potential security issues. We introduce Block Public Access, a tool that formally verifies policies to ensure that they only allow access to trusted principals, i.e. that they prohibit access to the general public. To this end, we formalize the notion of Trust Safety that formally characterizes whether or not a policy allows unconstrained (public) access. Next, we present a method to compile the policy down to a logical formula whose unsatisfiability can be (1) checked by SMT and (2) ensures Trust Safety. The constructs of the policy DSLs render unsatisfiability checking PSPACE-complete, which precludes verifying the millions of requests per second seen at cloud scale. Hence, we present an approach that leverages the structure of the policy DSL to compute a much smaller residual policy that corresponds only to untrusted accesses. Our approach allows Block Public Access to, in the common case, syntactically verify Trust Safety without having to query the SMT solver. We have implemented Block Public Access and present an evaluation showing how the above optimization yields a low-latency policy verifier that the S3 team at AWS has integrated into their authorization system, where it is currently in production, analyzing millions of policies everyday to ensure that client buckets do not grant unintended public access